fix(workflows): load custom steps before add - #4473

The fix itself is right (review's green, ubuntu passes), but your new regression test test_add_loads_custom_steps_after_resolving_project fails on macOS and Windows — CI shows AssertionError: assert [PosixPath('/...')] == [PosixPath('/...')] where the paths look identical but compare unequal. That's the macOS /tmp→/private/tmp (and Windows short-path) symlink normalization: tempfile paths don't round-trip through .resolve(). Please make the assertion resolve both sides first — e.g. compare [p.resolve() for p in loaded_roots] == [tmp_path.resolve()] (or assert on the resolved project_root). Re-request review once CI is green across all runners

@mnriem
The test fix is pushed.
I also ran the focused regression test on macOS and Linux, and it passed:

tests/test_workflows.py::TestWorkflowAddCaseInsensitiveSuffix::test_add_loads_custom_steps_after_resolving_project PASSED

The path comparison now resolves both paths before asserting equality.
Could a maintainer please approve or rerun the CI workflow so the Windows runners can verify the fix?

Thanks @ton-katsu — the macOS/Linux test failure is sorted, appreciated. One more from the latest automated review, and it's a real one: test_add_loads_custom_steps_after_resolving_project is currently tautological — it mocks load_custom_steps to a no-op and uses a built-in-step workflow, so it only proves the loader was called, and would still pass if the fix regressed (e.g. if the load moved after validation). Could you make it a genuine regression: have the workflow reference a custom step, have the loader actually register that step, and assert the workflow adds successfully — such that the test fails if loading happens after validation? The fix itself is right; this just makes the test guard it.

@mnriem
Thanks for the careful review. I updated the regression test to exercise the actual behavior:

• It creates a temporary custom step package with step.yml and __init__.py.
• The workflow references that custom step type.
• The real load_custom_steps() loader registers the step.
• The test asserts that workflow add succeeds and installs the workflow.

This means the test fails if custom-step loading is moved after workflow validation. The test passes on Linux and macOS.
I also verified that the test fails when run against the pre-fix version of _commands.py, confirming that it protects against the original regression.